Software Defined Network/Networking (SDN) involves decoupling network control from forwarding functions and allowing a centralized network controller to control the behaviour of the entire network. Thus, a network operator may, via high level SDN controller, specify the behaviour of the entire network compared to conventional networks in which the network operator needs to perform low level configuration of each device in order to specify the behaviour of the network. The static architecture of conventional networks are not known to be optimal for today's constantly changing dynamic traffic patterns, increasing storage needs, increased network complexity etc. One of the purposes of the SDN is to overcome these shortcomings of such conventional networks. In other words, a SDN enables flexible implementation of networks that may be dynamically provisioned.
Service chaining is a concept that has obtained increased importance with the rise of SDN. A service chain may be described as at least one service in a specific order and chained together to provide a complete service. Service chaining may be described as a mechanism for creating service chains and forwarding traffic flows through the chains. The forwarding of the traffic flows may be based on subscription. With SDNs, network operators are enabled to dynamically handle (e.g. create, modify, remove) service chains. A traffic flow may be forwarded through a service path in a service chain, and there may be multiple service paths in a service chain. A traffic flow may consist of data packets.
Currently, service chaining is mostly done through selection of individual user sessions with five-tuple filtering for every hop in the service chain. Another solution is that all selected traffic need to pass a service, independent of whether it is needed, just to simplify the traffic steering rules. In other words, without service chaining, all traffic flows need to pass a service for it to affect the traffic that is actually is interested in.
A problem with existing solutions is that they are scaling poorly for either the number of different traffic paths that may be handled (due to complexity to configure and set up), or the number of users that may be steered into the different traffic paths (due to the number of rules that need to be maintained to select them).
Another problem is that the scaling in the downlink direction is troublesome independent of the problems above as it is always scaling poorly for the number of users/sessions in line with the problem regarding that the number of users that may be steered into the different traffic paths as mentioned above.
Furthermore for Layer 2 (L2)—based service chaining, services, also referred to as applications, are unaware of the topology in the network and the applications/services will then in most cases destroy the tagging/chain data on L2 and a new classification is needed by the network to restore the tagging/chain data once an application/service has been applied to a traffic flow.
When selecting a path through several services for a specific flow, the total number of rules that need to be maintained throughout the path is a problem.